Folding Forum

HaloJones wrote:I could run a single Windows SMP client on my quad and get around 2200ppd. (Let's pretend that the ppd reflects the benefit to Stanford.)
I actually run two Linux VMs each limited to 2-cpus. Each Linux VM runs two Linux SMP clients. This gets 4400ppd.

Now some people get all hot under the collar and complain that I'm delaying the return of the results but if they're making the deadline that can't be a problem for Stanford - after all, they set the deadline, not me. Secondly, it must also be of benefit to Stanford because more work gets done.

And finally, doesn't it prove that running a single SMP client on a quad is a massive waste of potential resource?

HaloJones wrote:If they're dependent on each other then surely there must be a sequential aspect that prevents them being efficient on a 4x1 instead of a 1x4.

Oh, and "trust me, you're not running 4 smp clients on a quad core"? Do you have any idea how patronising that sounds? I'm a Technical Architect at a massive UK retailer with 25 years in IT. I know precisely what I'm doing, thank you very much! I was running two smp units on each vm so yes, that was 16 fahcore_a? processes on a quad. Why would you think that isn't possible; it's very possible. Must I provide pictorial proof?

HaloJones wrote:Hmm, if you're running notFred's distro you don't have a gui but try this instead. You presumably know the IPs of your VMs, so use something like putty to ssh onto the notFred VM and once logged in, try running "top". What you'll see is that the VM doesn't show 100% usage on the cpu. The four cores running on two actual cpus should fully utilise the two but it doesn't. Even the a2 cores don't. That delta is why it's more efficient to run two clients on each VM. With eight processes running in each VM, you'll see full utilisations of each cpu within the VM.

So, I've just fired up a VM. With a single instance of an a1 unit, the VM shows an average idle time of around 15%. That's four processes on two cpus yet it doesn't fully load them. That holds true with two VMs on a quad. You'll be wasting around 15% of the capability of the quad. You should really run three of NotFred's distros and see what you gain. Even with the disadvantage of increased context switching you'll still benefit in terms of total units crunched. Each one will take longer and only you can say if they still fit inside the deadlines. With my quad at 3.2GHz and running 24/7 the deadlines are not an issue.

WangFeiHong wrote:@Mtm, shattersilicon,

relax it's only a question on CPU infrastructure and software (SMP).....besides 138 isn't that high

i wish they could have separate stats for SMP and classic... then we can compare FLOPS (tho SMP would probably own it coz everyone's using duo, tris, quads and all at high clocks :O)

shatteredsilicon wrote:Specifically, on the setup that I'm using, I have 6x GPU clients and a quad-core CPU. Each GPU client consumes around 20% of a single core (it's actually a bit less, but 20% is 1/5, a nice round number for the sake of the explanation. Here's an ASCII-art example of what happens when all run at the same time, with a single SMP client.

First line is the CPU core number. G is GPU client's CPU usage, I is idle CPU time, S is SMP client's CPU time.

Code: Select all

0 1 2 3
G G G G
G I G I
S S S S
S S S S
S S S S

Essentially, it means that there's 40% of one core not being used, due to the fact that the MPI scheduler not being quite up to the task of balancing the workload distributed to the cores. What happens then is that the OS process scheduler notices that the SMP cores want to use more CPU, so it tries to reschedule things to optimize the CPU utilization, and starts throwing processes around from core to core trying to do a better job. This starts introducing CPU migration latencies (typically 100-150ns) all over the place, and the performance drops through the floor. If you had a single core (or bound a process set, such as a single instance of an SMP client to a single core) this imbalance and process migration wouldn't happen, thus yielding a massive saving in wasted CPU time, which will increase the WU throughput. As I said, I have observed a difference of 2x under real-world conditions.

Even theoretically, 1x4GHz will come out at worst equal and on average significantly ahead of a 2x2GHz solution. Trust me - I'm a computer scientist.

00 01 02 03
G1 G3 G4 G6
G2 S2 G5 S2
S1 S2 S1 S2
S1 S2 S1 S2
S1 S2 S1 S2

WangFeiHong wrote:1. He is using 1 SMP client read the table carefully the "S' represents usage of the core.

2. There is no throttling in SMP clients (viewtopic.php?f=46&t=6888&start=0&st=0&sk=t&sd=a&hilit=throttle) so you can't specify % for each core/client

3. I think it was mentioned here that cores need to play catch-up with each other in SMP, which is especially obvious when at the end of a WU, when you can see some of the 4 threads still running while the others have finished and are idling.

HaloJones wrote:Now some people get all hot under the collar and complain that I'm delaying the return of the results but if they're making the deadline that can't be a problem for Stanford - after all, they set the deadline, not me. Secondly, it must also be of benefit to Stanford because more work gets done.

MtM wrote:

shatteredsilicon wrote:Specifically, on the setup that I'm using, I have 6x GPU clients and a quad-core CPU. Each GPU client consumes around 20% of a single core (it's actually a bit less, but 20% is 1/5, a nice round number for the sake of the explanation. Here's an ASCII-art example of what happens when all run at the same time, with a single SMP client.

First line is the CPU core number. G is GPU client's CPU usage, I is idle CPU time, S is SMP client's CPU time.

Code: Select all

0 1 2 3
G G G G
G I G I
S S S S
S S S S
S S S S

Essentially, it means that there's 40% of one core not being used, due to the fact that the MPI scheduler not being quite up to the task of balancing the workload distributed to the cores. What happens then is that the OS process scheduler notices that the SMP cores want to use more CPU, so it tries to reschedule things to optimize the CPU utilization, and starts throwing processes around from core to core trying to do a better job. This starts introducing CPU migration latencies (typically 100-150ns) all over the place, and the performance drops through the floor. If you had a single core (or bound a process set, such as a single instance of an SMP client to a single core) this imbalance and process migration wouldn't happen, thus yielding a massive saving in wasted CPU time, which will increase the WU throughput. As I said, I have observed a difference of 2x under real-world conditions.

Even theoretically, 1x4GHz will come out at worst equal and on average significantly ahead of a 2x2GHz solution. Trust me - I'm a computer scientist.

You are a scientist? Why then have you got problems with rebuting the above quote, which you try to do with examples and arguments which aren't specific to the question/situation at hand? Trust me, I am not a scientist but I am eligible for Mensa and I can see you're just not hitting the mark with your 'observations'. ( sorry people who read this, but he said he's a 'scientist' lol )

MtM wrote:

shatteredsilicon wrote:I promise you, I'm not picking on you specifically. I apologize if it looks that way. Perhaps I shouldn't have inserted a snippet from your post, and stuck purely to answering the original question asked. I'll try to not repeat that mistake.

It's a mistake if you think you can talk all this nonsence and think I will not respond to correct your pile of BS You're not answering any original question at all you're only repeating this discussion in a thread I posted in before you because you're hoping I will get abit red hot or something, that's your motive nothing else.

MtM wrote:Singl;e core is not the same, first of all which current cpu has a single core variant? Oww... ok then.

shatteredsilicon wrote:

MtM wrote:

shatteredsilicon wrote:Specifically, on the setup that I'm using, I have 6x GPU clients and a quad-core CPU. Each GPU client consumes around 20% of a single core (it's actually a bit less, but 20% is 1/5, a nice round number for the sake of the explanation. Here's an ASCII-art example of what happens when all run at the same time, with a single SMP client.

First line is the CPU core number. G is GPU client's CPU usage, I is idle CPU time, S is SMP client's CPU time.

Code: Select all

0 1 2 3
G G G G
G I G I
S S S S
S S S S
S S S S

Essentially, it means that there's 40% of one core not being used, due to the fact that the MPI scheduler not being quite up to the task of balancing the workload distributed to the cores. What happens then is that the OS process scheduler notices that the SMP cores want to use more CPU, so it tries to reschedule things to optimize the CPU utilization, and starts throwing processes around from core to core trying to do a better job. This starts introducing CPU migration latencies (typically 100-150ns) all over the place, and the performance drops through the floor. If you had a single core (or bound a process set, such as a single instance of an SMP client to a single core) this imbalance and process migration wouldn't happen, thus yielding a massive saving in wasted CPU time, which will increase the WU throughput. As I said, I have observed a difference of 2x under real-world conditions.

Even theoretically, 1x4GHz will come out at worst equal and on average significantly ahead of a 2x2GHz solution. Trust me - I'm a computer scientist.

You are a scientist? Why then have you got problems with rebuting the above quote, which you try to do with examples and arguments which aren't specific to the question/situation at hand? Trust me, I am not a scientist but I am eligible for Mensa and I can see you're just not hitting the mark with your 'observations'. ( sorry people who read this, but he said he's a 'scientist' lol )

OK - explain how it isn't specific to the question/situation at hand. The subject line says: "Dual-core 2Ghz vs Single-core 4Ghz - Which faster?". You really should learn to read, since you don't seem to have parsed the subject line, let alone the contents of the post. I have answered this question with theory background and practical examples, both specifically relating to the folding SMP client and the general concept of breaking up a process into parallelizable tasks. Which part of that did you miss?

MtM wrote:

shatteredsilicon wrote:I promise you, I'm not picking on you specifically. I apologize if it looks that way. Perhaps I shouldn't have inserted a snippet from your post, and stuck purely to answering the original question asked. I'll try to not repeat that mistake.

It's a mistake if you think you can talk all this nonsence and think I will not respond to correct your pile of BS You're not answering any original question at all you're only repeating this discussion in a thread I posted in before you because you're hoping I will get abit red hot or something, that's your motive nothing else.

Not really. I've given up on educating you.

MtM wrote:Singl;e core is not the same, first of all which current cpu has a single core variant? Oww... ok then.

Since you asked - among the current line x86 CPUs: Core2 Solo and Athlon 64. Sill in production, still available.

Oh, and many thanks Halo - you seem to have successfully gotten through the points I've been (unsuccessfully, I was almost about to conclude futilely) trying to make. Fold on.

7im wrote:When running a race, the goal is to finish first. NOT to finish just before they close the race course.
...
Folding is relay race, with each WU being returned the quickest is the most helpful to the project. Follow the recommendations or don't, but higher PPD is NOT exactly equal to helping the project more. Fold on.