Folding Forum

WangFeiHong wrote: if i run SMP on 2Ghz Dual Core vs. 4Ghz Single Core, shouldn't we see similar FLOP performance?

WangFeiHong wrote:Just a quick question. It's said SMP alot faster than classic because they have some program that can let cores "talk" to each other very fast? But does it really do any calculations?

WangFeiHong wrote:If it's only inter-core communication that makes SMP faster, then what difference is it from 2 classic client, do 2 WU, then results getting joined back up at Stanford (except it save them time joining results?)

WangFeiHong wrote:The "talking" between cores doesn't do any calculations, so if i run SMP on 2Ghz Dual Core vs. 4Ghz Single Core, shouldn't we see similar FLOP performance?

WangFeiHong wrote:If it's only inter-core communication that makes SMP faster, then what difference is it from 2 classic client, do 2 WU, then results getting joined back up at Stanford (except it save them time joining results?)

MtM wrote:changed to quad core setup as the smp client is designed for four threads and it runs best on four cores

shatteredsilicon wrote:In general, single fast core scales linearly up to the point where it is I/O (network/disk/memory) bound.
Multiple cores scale linearly only if all the operations are completely independent. This is very rarely the case in practice, so in general usage, 1x 4GHz is going to be faster than 2x 2GHz.

As a rule of thumb, in desktop application usage, performance scales linearly with clock speed, but logarithmically with the number of cores.

There are also overheads in migrating processes between CPU cores. C2Q tends to suffer from this more than the Phenom X4 due to it actually being a 2x2 design vs 4x1 on the Phenom. But there are STILL migration overheads, nonetheless.

In the context of folding, you can easily test this. Fire up the SMP client on a 4-core CPU. See how many PPD it is producing when the 4 threads run freely on the available CPU cores. Then fire up 4 SMP clients, binding each client to only one core (all 4 of it's threads will run on a single core). So you will end up with 4x4=16 folding processes running, 4 bound to each CPU core. What you will find is that the PPD of the latter (4x4) configuration is significantly higher than that of the former (4x1) configuration. This difference is made worse if the machine is experiencing other load (applications), because due to an inefficiency in the folding process distribution design, all threads seem to have fixed weighting, so if one thread bogs down, they will all slow down, which will result in a flurry of process migration (overheads) and thread imbalances (CPU idle time). In the case of 4x4 this won't be the case because there is no migration between the cores, and if some process is eating 20% of one core, all it will do is reduce CPU resources for the folding processes from 25% each to 20% each, and they'll still balance out.

So, if you want maximum PPD out of your SMP client, run one instance per core, and bind each instance to one core so it never migrates away from it. The difference can be massive in some cases. For example, since I run 6x GPU clients (no way to distribute them evenly over 4 cores), one SMP client will produce about 2200PPD. If I start 4 SMP clients and bind each one to it's own core, the total production of the 4 clients is about 4700 PPD. This is despite the fact that each client has less memory bandwidth (1/4 of what a single client has available). At that point, however, the client tends to get memory bound, so if you run a 4x4 configuration, the Phenom X4 may well scale better due to the fact that it has over 50% more RAM bandwidth than an equivalent Core2.

MtM wrote:changed to quad core setup as the smp client is designed for four threads and it runs best on four cores

I guess we'll just have to disagree on that again. I've presented my evidence, and without evidence, once can only have an opinion.

Back in the day, we couldn't get long trajectories. By long I mean, we couldn't even come close to getting simulations that were comparable to the time it typically takes for a protein to folding in experiments. For example, the villin headpiece molecules fold in about 50 microseconds in a test tube. Simulations were originally limited to maybe 50 or 100 nanoseconds, about 1,000 times less. The idea is that the probability of a 50-nanosecond trajectory resulting in a folding event, for a protein that folds in 50 microseoncds on average, is

p(folding) = 1 - exp[ -( 50 ns )/( 50,000 ns ) = ~ 0.1 %

It's kind of like flipping a biased coin: say 99.9 % of the time, you get heads, but if you're lucky one one flip you *might* get tails. Of course, if you want to see tails, then you could always try to flip a lot, and occasionally (like 1 in every 1,000 flips) you'll observe heads. Likewise, if there's ~0.1% chance of observing folding in a 50-ns trajectory, then if we run 1,000 simulations then on average one of them should fold, if we run 10,000 simulations then ~10 should fold, etc. This is the reason for F@H in the first place: thousands of client machines mean thousands of "coin flips" or attempts to fold the protein, which increases our chances of actually seeing tails or a protein fold.

(The key here is the randomness in the simulations, best represented by random kinetic energy. When we say some system is at some temperature, we are really making a statement about the distribution of kinetic energies of the particles, but nothing about specific kinetic energies about specific particles. What we do is to initially supply kinetic energies to all the particles that are consistent with the specified temperature in a random way. When you do this, then the analysis in the proceeding paragraph makes sense.)

So in the "early days" F@H simulations, completing more work units was better for the project: basically everyone's machines were doing the computational-chemical equivalent of flipping coins. We'd send a work unit to your machine, which would compute the result of the "coin flip" (by moving atoms around according to their kinetic energy, their interactions with one another, and by applying Newton's laws of motion).

The newer way of thinking about things is essentially a test of whether the formula I used to calculate the percent chance of folding is accurate. If everything is simple, that simple exponential formula applies, but experimental evidence, let alone Murphy's law, would seem to indicate that things aren't so simple. For example, there could be two exponentials, not just one, and using the strategy above you'd really only see the first (faster) exponential. The contemporary approach relies on really fast machines (SMP, GPU, PS3, etc.) to make trajectories longer, instead of doing more trajectories: running a new Gen for the same Run/Clone rather than starting a new Gen 0 for a new Run/Clone. This way we can see if there is more complicated behavior. And the way to get this done is to use fast hardware with fast turnaround (deadline) times, because we need the Gen you're working on back before we can start to work on the next Gen.

MtM wrote:And then I'm not even talking about the 'mistakes' in your post, it's just your pov in general being so wrong that I don't even need to.

WangFeiHong wrote:The "talking" between cores doesn't do any calculations, so if i run SMP on 2Ghz Dual Core vs. 4Ghz Single Core, shouldn't we see similar FLOP performance?

shatteredsilicon wrote:

MtM wrote:And then I'm not even talking about the 'mistakes' in your post, it's just your pov in general being so wrong that I don't even need to.

Allow me to point you at a snippet from the original post in this thread:

WangFeiHong wrote:The "talking" between cores doesn't do any calculations, so if i run SMP on 2Ghz Dual Core vs. 4Ghz Single Core, shouldn't we see similar FLOP performance?

Since all things being equal (same project WU), the number of points for the WU will be fixed, as will the number of FLOPs required to process it. Thus, FLOPs will be proportional to points. Therefore, more points will yield more FLOPs, and higher number of processed WUs per (larger) unit of time (e.g. per month). What I have provided is information on how to minimize overheads and increase the long-term WU throughput, i.e. the amount of science being done per processor per month, if you will. That seems pretty relevant to what the original poster asked. The point is that a 2x2GHz will yield lower performance than 1x4GHz every time, which is what was being asked in the very subject line of the thread.

MtM wrote:Amount of science done is not dependant on throughput of wu's can't you read or are you just trying to perpetuate your wrong arguments with more wrong arguments?

MtM wrote:FLOPS and PPD don't have that tie when you talk about single core vs multi core ( or even comparing single cores with eachother but see 7im's post for that ), multi core enabels more complex workunits which are diffrent then the single core work units in their complexity and/or simulation length.

MtM wrote:2x2 = more then 1x4 because you run those complex work units on them which couldn't be ran ( within reasonable times or due to hw limitiations ) on a 1x4.

MtM wrote:The scaling is very much non linear, and I'm not adressing utilisation of cores, but scaling in work unit complexity and that is the tie to scientific results. Not your constant refering to ppd being a good indication while you know it is not.

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

MtM wrote:If I didn't know any better. I would say you where trying to get into an argument with me by taking the opposite stance in this... again.

I think you need to read the quote above again.

uncle_fungus wrote:Calm down people, there's no need to get hot under the collar about this.

We could just run multiple independent clients, but this would be throwing away a lot of power. What makes an SMP machine special is that it is more than just the sum of the individual parts (CPU cores), since those cores can talk to each other very fast. In FAH, machines talk to each other when they return WUs to a central server, say once a day. On SMP this happens once a millisecond or so (or faster). That 86,000,000x speed up in communication can be very useful, even if there isn't 100% utilization in the cores themselves.

there are some calculations which require fast interconnects, and that's where the FAH/SMP client is particularly important.
http://folding.typepad.com/news/2008/07/fahsmp-q-a.html

In FAH, we've taken a different approach to multi-core CPUs. Instead of just doing more WU's (eg doing 8 WU's simultaneously), we are applying methods to do a single WU faster. http://folding.typepad.com/news/2008/06 ... re-do.html

They give us considerably longer trajectories in the same wall clock time, allowing us to turn what used to take years to simulate even on FAH, to a few weeks to months........whereas the SMP client can lead to a 4x speed up over the complete range of calculations we need to run. http://folding.stanford.edu/English/FAQ-SMP

shatteredsilicon wrote:

MtM wrote:Amount of science done is not dependant on throughput of wu's.

That sounds like a contradiction in terms to me. For the record, I understand there is some extra usefulness in a WU being completed quicker, but even though this is the only argument you could be using against what I said, you seem not have gotten to that point (or were you partaking in this discussion with too limited an understanding?).

shatteredsilicon wrote:

MtM wrote:FLOPS and PPD don't have that tie when you talk about single core vs multi core ( or even comparing single cores with eachother but see 7im's post for that ), multi core enabels more complex workunits which are diffrent then the single core work units in their complexity and/or simulation length.

Actually, I was only talking about SMP clients with SMP work units. I never made any mention, nor was I intending to imply using single-processor WUs. Everything I said was only referring to SMP WUs (a2, 4-thread ones for quad-core CPUs, to be most specific).

shatteredsilicon wrote:

MtM wrote:2x2 = more then 1x4 because you run those complex work units on them which couldn't be ran (within reasonable times or due to hw limitiations) on a 1x4.

There are no such hardware limitations (even theoretically). Parallelized task can run at best scale linearly, although achieving such scalability this is highly unusual in the real world. You can run an SMP client on a single-core processor. As long as that CPU is at least around a 1.6GHz Core2 class processor, provided it is running 24/7 with no other significant load, it will still make the deadline for most SMP WUs. I'm not sure how that holds for 3 or 8-core WUs, the deadlines may require a faster single core than 1.6GHz, I haven't tested this configuration.

shatteredsilicon wrote:

MtM wrote:The scaling is very much non linear, and I'm not adressing utilisation of cores, but scaling in work unit complexity and that is the tie to scientific results. Not your constant refering to ppd being a good indication while you know it is not.

Actually, any SMP WU will quite happily run on a single-core processor. There is nothing that SMP provides other than that WU completes faster. There is no extra complexity that using multiple processors magically solves, which is what you seem to be implying. The problem is that overheads eat much of the gain, as I explained. The MPI process controller seems to use a naive round-robin scheduler, which makes the throughput suffer very heavily when the machine has any other load going on. Running 4 threads on an idle 4-core CPU will yield very good results. But the moment you do something else, and you generate, say,50% load on one core, what'll end up happening is that all 4 workers will only run at 50%, because it only seems to scale at 4x the slowest worker thread - and that is not including the problem of migration of processes between processor cores, which will make the scaling slightly worse still.

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.

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.