Just started GPU's on Einstein

[spingadus]

<app_info>
<app>
    <name>einsteinbinary_BRP4</name>
    <user_friendly_name>Binary Radio Pulsar Search (Arecibo)</user_friendly_name>
</app>
<file_info>
    <name>einsteinbinary_BRP4_1.00_windows_intelx86__BRP3cuda32.exe</name>
    <executable/>
</file_info>
<file_info>
    <name>cudart_xp32_32_16.dll</name>
    <executable/>
</file_info>
<file_info>
    <name>cufft_xp32_32_16.dll</name>
    <executable/>
</file_info>
<file_info>
    <name>db.dev.win.3d35195e</name>
</file_info>
<file_info>
    <name>dbhs.dev.win.3d35195e</name>
</file_info>
<app_version>
    <app_name>einsteinbinary_BRP4</app_name>
    <version_num>100</version_num>
    <platform>windows_intelx86</platform>
    <avg_ncpus>0.200000</avg_ncpus>
    <max_ncpus>1.000000</max_ncpus>
    <flops>32706701893.376610</flops>
    <plan_class>BRP3cuda32</plan_class>
    <api_version>6.13.0</api_version>
    <file_ref>
        <file_name>einsteinbinary_BRP4_1.00_windows_intelx86__BRP3cuda32.exe</file_name>
        <main_program/>
    </file_ref>
    <file_ref>
        <file_name>cudart_xp32_32_16.dll</file_name>
        <open_name>cudart32_32_16.dll</open_name>
        <copy_file/>
    </file_ref>
    <file_ref>
        <file_name>cufft_xp32_32_16.dll</file_name>
        <open_name>cufft32_32_16.dll</open_name>
        <copy_file/>
    </file_ref>
    <file_ref>
        <file_name>db.dev.win.3d35195e</file_name>
        <open_name>db.dev</open_name>
        <copy_file/>
    </file_ref>
    <file_ref>
        <file_name>dbhs.dev.win.3d35195e</file_name>
        <open_name>dbhs.dev</open_name>
        <copy_file/>
    </file_ref>
    <coproc>
        <type>CUDA</type>
        <count>0.500000</count>
    </coproc>
    <gpu_ram>314572800.000000</gpu_ram>
</app_version>
</app_info>

I created an updated "GPU ONLY" app_info for Einstein. I tested it and it works fine. Just change the gpu_ram line to suit your card.

I did this because I wanted to get my gpu usage % maxed out as it was only around 60%. Seems like a waste of gpu power to run it like that. The app_info will run 2 wu's per gpu. So far, it appears that it is still running at around 60%, so even though I have 2 tasks running at a time, it will now take 2 times as long to finish, so it's a wash.

I have 2 threads free and overall cpu usage is at around 90%, so I have room to spare.

I may fiddle with the following to see if increasing the values helps.
<avg_ncpus>0.200000</avg_ncpus>
<max_ncpus>1.000000</max_ncpus>

Anyone successful in getting Einstein@home to use all of your GPU?

[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?

[Slicker]

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?

For BOINC, you need to know C for both the apps and the server. You really don't need to know php since the web pages are plug and play. For GPU, OpenCL is your best bet as it really just a subset of C.

[spingadus]

For BOINC, you need to know C for both the apps and the server. You really don't need to know php since the web pages are plug and play. For GPU, OpenCL is your best bet as it really just a subset of C.

Thanks, when you say 'C', do you mean C++ as well?

[Slicker]

Thanks, when you say 'C', do you mean C++ as well?

90% C code, 10% C++. Just the basics of C++ though. Coprocessors (e.g. AMD, nVidia, OpenCL) use a base class of COPROC. There are lots of pointers to structures and the use of vectors to iterate through lists of things (WUs, coprocs, etc.).

[spingadus]

90% C code, 10% C++. Just the basics of C++ though. Coprocessors (e.g. AMD, nVidia, OpenCL) use a base class of COPROC. There are lots of pointers to structures and the use of vectors to iterate through lists of things (WUs, coprocs, etc.).

Thanks, I'm going to start brushing up on some C and see where it goes. It'll probably be a while before I gain any type of proficiency, but here's to another hobby.

[Fire$torm]

Thanks, I'm going to start brushing up on some C and see where it goes. It'll probably be a while before I gain any type of proficiency, but here's to another hobby.

Cheers.