Gravitational Wave search O1 all-sky tuning (O1AS20-100T)

I'm not sure if it's intentional or not, but the shorter deadlines on these tasks have resulted in my client running them in preference to any Fermi tasks that haven't been issued at least a week ago.

Of course there are :-). Unfortunately, this whole conversation is not about the three Linux apps. My original message was in response to a comment about how slow a Windows app seemed to be. That response was directed at Daniels_Parents who has Windows 7 64bit but is running what seems to be a 32bit app (which is fine but perhaps slow).

For Windows, there are only two apps available, the 32bit app and a 64bit app labeled (AVX) - these two.

Windows/x86 							1.04 (SSE2)
Microsoft Windows running on an AMD x86_64 or Intel EM64T CPU 	1.04 (AVX)

I was just surmising that a non-AVX version of the Windows 64bit app seemed to be missing. I have no idea if the (AVX) Windows app is supposed to handle both types of 64bit CPUs (with or without AVX instructions). Perhaps that might be why. If so, why didn't the DP machine get the 64bit (AVX) app?

I'm going to agree and disagree with Robert.

Agree that the number of actual core vs hypterthreaded is going to affect how fast the GW work gets processed.

I run 6 core HT to 12 as well as a 8 HT to 16.

It's better to run only as many actual core than HT ones. Running with HT will significantly increase the time to complete.

GPU loads will also prolong time to complete as well but not as drastically.

Disagree with this part, I've seen it with Gamma ray searches on the CPU. So much so that I restrict how many are run while also crunching on the GPUs. It followed that the GW would behave the same way, which is why I restricted the number I was running at the beginning to only the number of actual cores.

My times now have increased (by about 35 minutes) only because I have restarted GPU work at the same time.

To mix in one post some comments on the "slow" results reported by daniels_parents, and the more recent comments here on hyperthreading with some data:

First, the data. The host mentioned by
Daniels_Parents is represented as an i7 CPU 920 @ 2.67GHz. That makes it a Bloomfield quad core which in turn means it is a rather modestly modified Nehalem at heart. I believe Arthur runs this with maximum loading, which may mean 8 CPU tasks (as it is running hyperthreaded) and the support CPU tasks for two Nvidia GPUs, all elbowing each other for the resources of four physical cores and the memory resources, both dedicated and shared. An eyeball average suggests he was getting roughly 79,000 second average elapsed times on V1.03/V1.04 x86 SSE2 O1AS20 work.

Meanwhile the host was also running Parkes PMPS work on two GPUS, a GTX 560 Ti and a GTX 760

As it happens I run one host with a pretty similar CPU, which is reported as a E5620 @ 2.40GHz, while nominally a Westmere, this, too, is a lightly modified Nehalem architecturally, though it gets power efficiency advantage from running on the next generation process.

Mine, however, runs a much different load configuration. During O1AS20 testing mine was running a single BOINC CPU task, but was supporting two GPUs (one GTX 750, and one GTX 660), both running at multiplicity 2X. As with the DP machine, the executable was labelled for SSE2 exploitation, and x86 (32-bit) character. An eyeball average of elapsed time is just under 52,000 seconds. This would certainly come down some if I suspended the GPU work, as I give the GPU support tasks privileged access by both priority and affinity means.

For power efficiency reasons, I've not been running CPU BOINC jobs at all for some months, and only recently admitted a single CPU task to each of my three GPU-supporting hosts during recent beta activities. So I lack recent carefully compared productivity on current applications for hyperthreading benefit.

However I have done careful, properly controlled, comparisons in the past, and have found the throughput improvement from HT on those cases to range between a little and a lot. The one plausible reported contrary case I recall came quite some time ago when msattler at SETI reported that on his (then heavily overclocked) rig, HT cost enough in maximum clock rate for correct operation that the gain in productivity per clock was overbalanced by the loss in clock rate. My own CPU overclocking days are rather far in the past, so this result, while compelling for him, does not affect me.

If people are actually seeing HT impairing output here, I doubt the reason is a simple failure of HT itself, but perhaps a congestion in some shared resource, most likely cache or external memory. Possibly this may be confounded by mixing in the GPU support tasks so many of us run these days.

I think I can define some controlled tests to investigate a little better the effects of HT itself vs. those of congestion, but lack the interest to take the time to execute them. To reduce the impact of shared memory resource congestion, I'd first make a comparison between a single task restricted to a single core, run non-HT, with all other important active tasks banished from that core by affinity means, and not other BOINC, interactive work, and significant background tasks running. The other leg of that first comparison would enable HT, running just two tasks, constrained by affinity to the two logical instances of a single physical core, with the same constraints on other work.

A further pair of tests might help promote or denigrate the shared resource congestion notion: run 4 tasks running non-HT then 8 tasks running HT. If the 8 to 2 comparison is inferior to the 4 to 1 comparison, then congestion might reasonably be suspected.