well i've been running these FGRP3 GPU tasks 6 at a time for a while now on my 7970 3GB GPU. utilization averages 58% +/- a 5% margin of error. this is in comparison to a ~55% utilization when running only 5 tasks at a time. so despite my inability to test more than 6 FGRP3 GPU tasks at a time due to VRAM limitations, i'm fairly confident that the law of diminishing returns is having its effect, and that i'm probably already near my GPUs limit for efficiency. in other words, i think the only way to increase GPU utilization at this point is to optimize the code (i.e. give the GPU more than just FFT calculations). i understand that this takes time and requires patience host-side.
There are CPU App versions of FGRP3 (plan class is "FGRPSSE"). If you didn't get work for that, you probably have to set "Run CPU versions of applications for which GPU versions are available" to "yes" in your Einstein@Home preferences. Currently FGRP3 is the only application affected by this setting, as the BRP search has separate applications for GPU (BRP5, BRP4G) and CPU (BRP4).
Hallo BM!
Thankyou for your quick response.
The problem for me is, that I get GPU work for FGRP3 than also, and this GPU work is running much less efficient on my system than BRP5. There is a factor 2 or 3 inbetween. So it is, with regard to Cobblestone earnage, for me more efficient to disable FGRP3, except I can select CPU work for FGRP3 only.
I appreciate your efforts, but as a 68 yr old pensioner and one who has not written code for over 30 yrs or so your solution does not apply to me. I don't know anything about ap info exml. What this thing needs, at least for me, is an option on the preference page is the choice of running on the cpu "FGRPSSE and leave the gpu alone with this little parasite. I don't mind running it on the cpu but it hogs too many resources when run on the gpu.
You´r right, on my PC these FGRPopend-ati taks require about 60% of the capabilities of one CPU-core at relative low GPU-load. But even this gives a benefit of 4.5, or in other words the FGRPobend-ati taks (running on CPU + GPU) are running only 22,22% as long as FGRPSSE taks (running only on CPU). As the GPU-load ist relative low - at me never higher than 60% and that only from time to time for some seconds long, - you can choose in the Einstein@Home preferences in your account the "GPU utilization factor of FGRP apps" lower than 1. If this factor is 0.5 and you have sufficient of VRAM on your graphicscard, there will run 2 tasks on your GPU. If you insert 0.33, there will run 3 tasks in parallel on the GPU, but you require for this at minimum 2GB of VRAM on your GPU. So you don´t require anymore these appinfo files.
I hope this will clarify a bit.
Martin I am running a GPU factor of .33 and when a FGRP3 runs it also requires a CPU core so when I had 3 up at once I only had 4 tasks running instead of 7 that being 4 on the CPU and 3 on the GPU.
I had 3 up at once I only had 4 tasks running instead of 7 that being 4 on the CPU and 3 on the GPU
Yes, that´s right, as you and I have an i5 processor, which can´t perform HT (hyper threading). But still it should give higher overall performance, as the GPU tasks are running much faster than the CPU only tasks.
So by theory. But in practice, as I observed first time yesterday, this isn´t so. With the program "MSI Afterburner" one can see the time dependend GPU-load. This shows for the FGRP taks a highly cluttered trace with often several second long very low or zero GPU-load inbetween. So by theory within this time could be easily crunched another task of the same kind. But if both task became started at the same time and they act so similar in time requiering the GPU, both tasks are very often overloading the GPU, instead of filling the timegap inbetween. It seems to help, halting one of the task for a minute or so and than continuing. The best timedelay has to be tested for. Hopefully one of the programmers could give us some hints in this regard.
I hope, my writing is understandable. If not, don´t hesitate to contact me.
Better now? (The problem
)
Better now?
(The problem is that on the server side we can't see that part on the Client side)
BM
BM
RE: Better now? (The
)
Yes, thank you! All is back to normal!
well i've been running these
)
well i've been running these FGRP3 GPU tasks 6 at a time for a while now on my 7970 3GB GPU. utilization averages 58% +/- a 5% margin of error. this is in comparison to a ~55% utilization when running only 5 tasks at a time. so despite my inability to test more than 6 FGRP3 GPU tasks at a time due to VRAM limitations, i'm fairly confident that the law of diminishing returns is having its effect, and that i'm probably already near my GPUs limit for efficiency. in other words, i think the only way to increase GPU utilization at this point is to optimize the code (i.e. give the GPU more than just FFT calculations). i understand that this takes time and requires patience host-side.
There are CPU App versions of
)
There are CPU App versions of FGRP3 (plan class is "FGRPSSE"). If you didn't get work for that, you probably have to set "Run CPU versions of applications for which GPU versions are available" to "yes" in your Einstein@Home preferences. Currently FGRP3 is the only application affected by this setting, as the BRP search has separate applications for GPU (BRP5, BRP4G) and CPU (BRP4).
BM
BM
Hallo BM! Thankyou for your
)
Hallo BM!
Thankyou for your quick response.
The problem for me is, that I get GPU work for FGRP3 than also, and this GPU work is running much less efficient on my system than BRP5. There is a factor 2 or 3 inbetween. So it is, with regard to Cobblestone earnage, for me more efficient to disable FGRP3, except I can select CPU work for FGRP3 only.
Kind regards and happy crunching
Martin
Maybe you might be interested
)
Maybe you might be interested in these notes?
Cheers,
Gary.
I appreciate your efforts,
)
I appreciate your efforts, but as a 68 yr old pensioner and one who has not written code for over 30 yrs or so your solution does not apply to me. I don't know anything about ap info exml. What this thing needs, at least for me, is an option on the preference page is the choice of running on the cpu "FGRPSSE and leave the gpu alone with this little parasite. I don't mind running it on the cpu but it hogs too many resources when run on the gpu.
Hallo Betreger! RE: it
)
Hallo Betreger!
You´r right, on my PC these FGRPopend-ati taks require about 60% of the capabilities of one CPU-core at relative low GPU-load. But even this gives a benefit of 4.5, or in other words the FGRPobend-ati taks (running on CPU + GPU) are running only 22,22% as long as FGRPSSE taks (running only on CPU). As the GPU-load ist relative low - at me never higher than 60% and that only from time to time for some seconds long, - you can choose in the Einstein@Home preferences in your account the "GPU utilization factor of FGRP apps" lower than 1. If this factor is 0.5 and you have sufficient of VRAM on your graphicscard, there will run 2 tasks on your GPU. If you insert 0.33, there will run 3 tasks in parallel on the GPU, but you require for this at minimum 2GB of VRAM on your GPU. So you don´t require anymore these appinfo files.
I hope this will clarify a bit.
Kind regrards and happy crunching.
Martin
Martin I am running a GPU
)
Martin I am running a GPU factor of .33 and when a FGRP3 runs it also requires a CPU core so when I had 3 up at once I only had 4 tasks running instead of 7 that being 4 on the CPU and 3 on the GPU.
Hallo Betreger! RE: I
)
Hallo Betreger!
Yes, that´s right, as you and I have an i5 processor, which can´t perform HT (hyper threading). But still it should give higher overall performance, as the GPU tasks are running much faster than the CPU only tasks.
So by theory. But in practice, as I observed first time yesterday, this isn´t so. With the program "MSI Afterburner" one can see the time dependend GPU-load. This shows for the FGRP taks a highly cluttered trace with often several second long very low or zero GPU-load inbetween. So by theory within this time could be easily crunched another task of the same kind. But if both task became started at the same time and they act so similar in time requiering the GPU, both tasks are very often overloading the GPU, instead of filling the timegap inbetween. It seems to help, halting one of the task for a minute or so and than continuing. The best timedelay has to be tested for. Hopefully one of the programmers could give us some hints in this regard.
I hope, my writing is understandable. If not, don´t hesitate to contact me.
Kind regards and happy crunching
Martin