CUDA Application under-performance

I set that last night, for much the same reasons. It has successfully inhibited a CUDA work request, but I would like to see whether the host will request work for the CPU (I still have both S5R6 and ABP1 CPU app_versions in client_state).

Unfortunately, at the precise time my host picked up the 'no_cuda' directive from Einstein, BOINC v6.10.19 stopped recalculating long-term debt for the project: so I'm stuck on "(overworked)" and no work fetch with no way down.

Both of you have access to the logs I've just posted on boinc_alpha: any ideas?

The E@H GPU app is very new and, as yet, not that much of the actual processing has been ported to the GPU. At this stage there is a speedup but probably not as much as people hope for and certainly not as much as there will be when the app is further developed and makes greater use of the GPU.

You have to be a bit careful when comparing your crunch times to those of someone else, particularly when you don't know how the other person has his machine configured. Yours is a quad core Q6600 and your wingman's is a dual core supposedly at only 2.0GHz. However your benchmarks (FP/Int) are listed as 2284/7228 whilst your wingman's are 2457/8874. It is highly likely that the machine is significantly overclocked.

Another possible factor is the performance of the app under different OS's (different compilers and switches) which can make a significant difference. Your wingman is using Darwin. It's interesting to note that you also have a dual core running Darwin and in the task list of that machine there is an APB1 task showing that also took only 14Ksecs. I don't know but it looks like the Darwin APB1 app may be pretty fast.

A third possible factor is that your wingman's task was completed in a single run without stopping. Yours had quite a few stop/starts, particularly towards the end. Click on the taskID for your task and scroll down and you can see each time the task was restarted from a checkpoint. If the app isn't permanently in memory, you will always lose a little bit each time you restart from a saved checkpoint. It isn't very much (checkpoints are just over a minute apart on your machine) so it should only make a relatively small difference but it can mount up if there is a lot of stopping and restarting.

It definitely is. For (Intel) Macs, the compiler knows that he will have at least SSE and SSE2 support (the earliest Intel Macs came with the 'Yonah' Core Duo or Core Solo chips). This will give the Darwin app quite an edge over the Linux and Windows apps that are optimized only for SSE.

The speedup is also in the part of the program that is NOT yet ported to CUDA, that's why the disadvantage of SSE-only-optimiziation is hurting the CUDA apps and the the CPU apps on Windows and Linux. So CUDA-OSX apps for the Macs would really run quite nicely, but it seems Apple (or NVIDIA) is a bit behind in making this work on the Mac, so there is no ABP1 CUDA app for Macs yet
.. you can't have it all, I guess.

Another issue is memory bandwidth and cache size. When comparing runtimes of ABP1 tasks executed on different (say) Core 2 CPUs but under the same OS, you'll see that nominally faster (in terms of clockrate) hosts are sometimes beaten by slower ones, if those have fewer cores and/or larger L2 caches.

Parts of the ABP1 app are rather memory intensive and every byte of cache does help. Probably that's the reason why (again), ABP1 is quite a bit slower on AMD consumer CPUs (with their typical 512 MB L2 cache per core) than you would expect from benchmarks.

CU
Bikeman