Just started GPU's on Einstein

[rgathright]

Does anyone have some advice for proper setup of the NVIDIA video cards in my machine on Einstein@home?

[Fire$torm]

I have not run the Einstein Cuda app but......

I do not believe the Cuda app is multi-threaded so you should see one wu for each GPU crunching it. For OverClocking your nVidia start at stock clocks and run a wu while checking GPU temp. When the wu is finished pause GPU work and up the GPU clock 20~25 Mhz and crunch another wu, again while monitoring GPU temp. Keep doing this until you reach the highest temp you are comfortable with or until you hit that cards OC limit. Whcih ever comes first. Then you are set to crunch to your hearts content.



Edit: I would suggest leaving the nVidia Mem Clocks at stock. Uping mem clock just adds a lot of heat without a significant increase in crunching performance.

[Bryan]

Check the forum for an app_info. Several of the top computers show as "anonymous platform" and it appears they are running 3 wu at a time. A GTX 570 appears to get about 32k per day. This is a pure guess on my part!

[Fire$torm]

Check the forum for an app_info. Several of the top computers show as "anonymous platform" and it appears they are running 3 wu at a time. A GTX 570 appears to get about 32k per day. This is a pure guess on my part!

Yeah, what he said....

[rgathright]

I have yet to reach full utilization of my GPU's in the computer.

Over at PrimeGrid, I was routinely hitting 192F on my 3 GPU's, now I am lucky to hit 160F at Einstein.

Should I tweak my Boinc settings to dedicate more cpu resources to the management of these Einstein CUDA WU's?

As always, THANK YOU for you support!

[Bryan]

Before you mess with your BOINC settings do this:

1. Use GPU-Z to monitor your GPU loading.
2. Go into BOINC Projects and suspend all CPU projects.
3. If the loading jumps up then the problem is with your CPU usage and if it doesn't then the problem is with the Einstein program.

I think this is why folks are running an app_info (anonymous platform) and crunching multiple wu at a time per card.

[Al]

I've gotten it up in the mid 80's but it still took twice as long, so I gave up on it.

[Slicker]

One of two things is going on here. Either the Einstein developers are college kids who haven't learned how to code for performance yet, or the app really doesn't lend itself to running on a GPU. You have a choice when programming for the GPU to do either blocking or non-blocking calls. Either way, the CPU has no clue what the GPU is doing when it is doing it. It only knows when it finishes. So, the question is whether the CPU does something else while it waits or whether it blocks all other programs from running while waiting. Choose wrong and the CPU wastes cycles that could have been spent elsewhere. By calculating how long it takes to run a GPU kernel (e.g. run 10 of them and take the average time), once can tell the CPU to "sleep" for that length of time so that it uses virtually no CPU at all. This is even easier though the use of events in OpenCL programming -- while clWaitForEvents(event) sleep(milliseconds).

GPUs are great at parallel tasks. But, every time one of the stream processors has to do something different than all the others (e.g. loop one extra time) then all the others have to wait for that one stream processor to finish. Only when all of them are finished can it move on to the next task. When 40% of the stream processors have to run extra instructions and the other 60% sit idle, you will see the app running at 40% GPU utilization. To fix that, one needs to break the kernels into smaller parts so that for each, all stream processors are 100% utilized. That, however, can't always be done.

One way to look at parallel processing is like this: You have 1000 cars driving from New York to California and all are supposed to arrive at exactly the same time. There is no such thing as a 1000 lane highway. So, it is impossible for all of them to arrive at exactly the same time since, assuming the road is two lanes wide, the cars would be stacked up 500 deep in line to cross the California border. You can attempt to use multiple roads so that there are fewer cars in line, but the logistics of getting all the cars on all the roads to cross at the same time is much more difficult than having to monitor a single road. So, in GPU programming, any time the application goes through a "Do command. OK, but...." that means it has to stop and wait because all streams run the same commands at the same time and none are allowed to jump ahead. If the math problem being solved doesn't lend itself to doing that, the GPU app won't run efficiently.

As I've said more than once before, just because you can use a table knife as a screwdriver, it doesn't mean you should. Just because a GPU can run an app doesn't make it the best use for the GPU. With the heavy CPU utilization and the limited GPU utilization, Einstein is fitting a square peg into a round hole. With a big enough hammer, you can get it to work. The real question is, should they even try?

[Fire$torm]

Thank you Slicker. GPU Programming 101: Introduction. Good stuff Professor Slicker.

[spingadus]

Yes, thanks Slicker. I enjoyed reading that and feel more educated as well

Makes me want to learn a programming language.

Any ideas what would be the ideal language these days to start on if you wanted to eventually create a BOINC project and code for both cpu and gpu?