Possible to run GPU tasks with otherwise fully loaded CPU ?
8 Sep 2014 10:15:50 UTC
Topic 197715
(moderation:
Hi,
I've been revisiting a couple of CPU/GPU projects and right now keeping the CPUs busy with a CPU only project.
I found that i.e. Collatz and MilkyWay are running just fine (not optimal of course but quite good) when being added to load existing GPUs besides all CPUs running. Their GPU threads with the single notch higher priority take their small needed CPU share and move at fairly good speed.
Einstein however, grinds to a near absolute halt when running on CPUs that are fully loaded with other tasks, even manually increasing its thread priority doesn't work.
Is there a way/tweak to let it chug along at acceptable performance in such a configuration ?
Possible to run GPU tasks with otherwise fully loaded CPU ?
)
Just limit the number of cpu's allocated to BOINC by one, no need
to mess with app_configs for any projects.
BOINC-->Tools-->Computing Preferences-->On Multiprocessor systems use at most
Input the percentage for a 4 cpu system input 75% etc you should see in Event Log the changes made in cpu's i.e. 4 to 3 CPU's
Einstein seems to need alot of PCI bandwidth as this is controlled via a CPU
a CPU needs to be free to honor those requirements.
You might squeeze a couple of percent increase by using Efmer's Priority program
but it doesn't help much here.
If someone knows of any other way to do this :-)
I know that would be the
)
I know that would be the normal way - but this time around I need all CPUs active for my CPU project (minus whatever small percentage Einstein would need to run).
Therefor this time I can't and won't sacrifice a full CPU core for a run-along project that only needs 5-10% of a core...
I've already set the Einstein GPU task Priority to its maximum, but that didn't help it to grab the CPU time it needs, the Task was running at about 2-3% of expected performance which makes no sense running.
This is an interesting topic.
)
This is an interesting topic. I believe it might also depend on how powerful GPU you are using. Muscular fast cards might slow down serious amount if all CPUs are running full blown and aren't able to feed the GPU in time. Though, it can well be these days that all new GPU's are already "too fast" and require very much dedicated time from the CPU, in Einstein kind of project.
I succeeded to build my first ever Linux host yesterday and after many difficulties I got my old Nvidia GT430 in it to run CUDA tasks for Einstein. That's a slow card, but the CPU in that host is also quite slow (dual core 3.3 GHz, LGA775 mobo).
First I let the GPU run Einstein alone for some time. Then I added another project and cranked the CPU both cores work 100% time for that project. Now I've been watching how much that did slow down the GPU. At this point it seems... didn't have almost any effect on the GPU speed. CPU still seems to have time to throw enough stuff for the slow GPU.
But that wasn't the situation with GTX780 and a LGA775 mobo + quad core CPU + Windows. With that combination, if all 4 cores were 100% reserved for CPU tasks, GPU processing speed went down a notably big step.
So I think it must depend somewhat on how powerful the motherboard/memory/cpu combination is... in relation to GPU power. But this might be kind of ancient "view" and all new GPU's are most likely so hungry they really need attention, even in an otherwise powerful build.
My combination is a FX-6300
)
My combination is a FX-6300 CPU with an older HD7790.
Both aren't high-end by any means but still do very decent work.
Monitoring GPU-Z, the Einstein GPU task was doing fine for as long as 1 core was left free.
As soon as the last core was used for a CPU task, Einstein GPU performance dropped like a rock. A ~4 hour task was predicted to take over a whole week is how bad it was :(
Couldn't fix that so far with any tricks I pulled.
For comparison under these conditions :
- SETI performs just fine, with expected loss of effectiveness
- MilkyWay runs very nice, little performance loss notable
- Collatz runs very nice, with distinct (but still acceptable) loss of effectiveness
It seems Einstein's heavy reliance on permanent I/O seems to hinder it under such conditions, at least in my case. The other projects in comparison rather place large work chunks entirely onto the GPU and have it solve them locally without much CPU interaction during that phase.
Einstein in contrast demands a free lane on the highway and slams the brakes as soon as it's placed into traffic ;)
Falcon you have been here
)
Falcon you have been here since 2005 and must have known about this issue with
ATI Graphics adapters, my GTX660 does not suffer from this, so another solution is
get an NVIDIA, However my HD7950's both suffer royally.
Edit - Hmm both my HD7950's are in ATI motherboards, Guess I'll have to move
one of my H7950's to my i5-3570k motherboard, to eliminate an ati chipset issue.
Since it works well on other
)
Since it works well on other projects with ATI, I figured it may work out here as well. Plus, the advancing BOINC versions keep improving on the issue - just not quite there yet *g*
I understand though that sometimes NVidia applications behave different than ATI OpenCL tasks.
The main reason I tried to make it happen was that I'd prefer Einstein over most other GPU projects ;)
Once I'm done with SIMAP, I'll be able to reserve CPU cores as needed again.
PS.
Overall I prefer ATI cards for their performance - but I did enjoy running a few NVidia cards for the SETI WoW!2014 challenge, they're indeed good CUDA performers and can cut an edge when it is used.